Skip to content

[TT-16977] fix: trigger release workflow on PR labeled event#975

Merged
buger merged 1 commit intorelease-1.14from
fix/pr-labeled-trigger-release-1.14
Apr 17, 2026
Merged

[TT-16977] fix: trigger release workflow on PR labeled event#975
buger merged 1 commit intorelease-1.14from
fix/pr-labeled-trigger-release-1.14

Conversation

@buger
Copy link
Copy Markdown
Member

@buger buger commented Apr 17, 2026

Summary

  • Add labeled to pull_request trigger types so dep-guard re-evaluates when deps-reviewed label is added.

Test plan

  • Adding deps-reviewed label triggers a new release workflow run

🤖 Generated with Claude Code

Adding deps-reviewed label after dep-guard fails didn't trigger a
new run. Add 'labeled' type so the workflow re-runs when the label
is added.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@buger buger requested a review from a team as a code owner April 17, 2026 13:58
@probelabs
Copy link
Copy Markdown
Contributor

probelabs Bot commented Apr 17, 2026

This PR updates the release.yml GitHub Actions workflow to trigger on the labeled event for pull requests. This allows the workflow to be re-run when a label, such as deps-reviewed, is added to a PR, ensuring that processes like dependency checks are re-evaluated after manual approval.

Files Changed Analysis

  • .github/workflows/release.yml: Modified to add labeled to the list of pull request types that trigger the workflow. This is a single-line configuration change.

Architecture & Impact Assessment

  • Accomplishment: The change enables the release workflow to react to labeling events on a pull request, integrating a manual review step (labeling) with the automated CI/CD pipeline.
  • Key Technical Changes: The on.pull_request.types array in the workflow's trigger configuration was expanded from [opened, synchronize, reopened] to [opened, synchronize, reopened, labeled].
  • Affected System Components: This change directly affects the repository's CI/CD release process managed by GitHub Actions. The primary impact is on the conditions that trigger the release workflow.

Here is a visualization of the trigger change:

graph TD
    subgraph Before
        A[PR Opened] --> B{Release Workflow};
        C[PR Synchronized] --> B;
        D[PR Reopened] --> B;
    end
    subgraph After
        A2[PR Opened] --> B2{Release Workflow};
        C2[PR Synchronized] --> B2;
        D2[PR Reopened] --> B2;
        E2[PR Labeled] --> B2;
    end
Loading

Scope Discovery & Context Expansion

  • The change is isolated to the workflow trigger configuration. However, its functional impact relates to the entire process orchestrated by the release.yml workflow. Based on the PR description mentioning dep-guard and the deps-reviewed label, this workflow is likely responsible for security and dependency validation before a release. By triggering on the labeled event, the workflow can now proceed after a required manual dependency review is marked as complete via labeling.
Metadata
  • Review Effort: 1 / 5
  • Primary Label: chore

Powered by Visor from Probelabs

Last updated: 2026-04-17T13:59:57.264Z | Triggered by: pr_opened | Commit: bf9fd9b

💡 TIP: You can chat with Visor using /visor ask <your question>

@probelabs
Copy link
Copy Markdown
Contributor

probelabs Bot commented Apr 17, 2026

Security Issues (1)

Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The `release.yml` workflow is triggered on the `pull_request` `labeled` event. This workflow contains a `release` job that is only intended for pushes to the `master` branch, which could lead to unintended behavior or resource consumption if triggered by labeling a pull request. The `release` job includes steps for building and pushing Docker images and creating GitHub releases, which should not run on pull request events.
💡 SuggestionTo prevent the `release` job from running on pull request events, add a condition to the job to ensure it only runs on pushes to the `master` branch. The `dep-guard` job already has a condition to run on pull requests, which is correct. Apply a similar, but more restrictive, condition to the `release` job.
  release:
    if: github.event_name == &#39;push&#39; &amp;&amp; github.ref == &#39;refs/heads/master&#39;
    needs: [linter, test]
    runs-on: ubuntu-latest

Security Issues (1)

Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The `release.yml` workflow is triggered on the `pull_request` `labeled` event. This workflow contains a `release` job that is only intended for pushes to the `master` branch, which could lead to unintended behavior or resource consumption if triggered by labeling a pull request. The `release` job includes steps for building and pushing Docker images and creating GitHub releases, which should not run on pull request events.
💡 SuggestionTo prevent the `release` job from running on pull request events, add a condition to the job to ensure it only runs on pushes to the `master` branch. The `dep-guard` job already has a condition to run on pull requests, which is correct. Apply a similar, but more restrictive, condition to the `release` job.
  release:
    if: github.event_name == &#39;push&#39; &amp;&amp; github.ref == &#39;refs/heads/master&#39;
    needs: [linter, test]
    runs-on: ubuntu-latest
\n\n ### Architecture Issues (1)
Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The `pull_request` trigger is configured to run on the `labeled` event, which will fire every time any label is added to a pull request. The pull request description states the intent is to react specifically to the `deps-reviewed` label. This broad trigger could lead to numerous unnecessary workflow runs, consuming resources and cluttering the Actions tab.
💡 SuggestionAdd a condition to the relevant job(s) within this workflow to ensure they only execute for the intended `deps-reviewed` label. A condition like `if: contains(github.event.pull_request.labels.*.name, 'deps-reviewed')` would ensure the job runs only when this specific label is present, which covers both initial PR creation and the `labeled` event.

Performance Issues (1)

Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The workflow trigger `labeled` will cause this workflow to run every time any label is added to a pull request. This can lead to excessive, unnecessary workflow executions, consuming CI/CD resources and potentially increasing queue times for other builds. The pull request description states the goal is to trigger for the `deps-reviewed` label specifically.
💡 SuggestionTo prevent unnecessary runs, add a condition to the job(s) within this workflow to check if the added label is `deps-reviewed`. This ensures the workflow only proceeds when the specific, intended event occurs.

Example condition for a job:

if: github.event.action != &#39;labeled&#39; || github.event.label.name == &#39;deps-reviewed&#39;

This condition allows the job to run for other pull request events (opened, synchronize, reopened) while restricting the labeled event to only the deps-reviewed label.


Powered by Visor from Probelabs

Last updated: 2026-04-17T13:59:29.494Z | Triggered by: pr_opened | Commit: bf9fd9b

💡 TIP: You can chat with Visor using /visor ask <your question>

@sonarqubecloud
Copy link
Copy Markdown

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@buger buger merged commit 6f989ec into release-1.14 Apr 17, 2026
40 of 43 checks passed
@buger buger deleted the fix/pr-labeled-trigger-release-1.14 branch April 17, 2026 14:06
@probelabs probelabs Bot changed the title fix: trigger release workflow on PR labeled event [TT-16977] fix: trigger release workflow on PR labeled event Apr 17, 2026
@github-actions
Copy link
Copy Markdown
Contributor

🚨 Jira Linter Failed

Commit: bf9fd9b
Failed at: 2026-04-17 16:49:36 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details
failed to get Jira issue: failed to fetch Jira issue TT-16977: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

Next Steps

  • Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
  • Verify your PR title matches the branch's Jira ticket ID
  • Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant